Technical Field
The present invention relates to a process for providing trickplay operations, such as rewind and fastforward, with a system that uses Broadcom Transport Packets (BTP) with more recent video standards than MPEG2 for which the BTPs were designed.
Related Art
Digital Video Recorder (DVR) capable set top boxes can record content for viewing at a later time. The recorded content can be skipped, Fast Forwarded (FF) or Rewound (REW) at different speeds, together known as trickplay operations. The recorded content could be of any format like MPEG2 or MPEG4. Introducing new format types brings in advantages as well as complications into the editing system.
Complications that are brought in when a new format is adopted can be seen in the case of introduction of MPEG4. System-on-a-Chip (SoC) provider Broadcom (BCM) makes SoCs used in set top boxes that are DVR capable. Broadcom uses their concept of “Broadcom Transport Packet” (BTP) to support trickplay of a MPEG2 transport stream. The BTP is used for accurate identification of I frames with MPEG2. The BTP packets are required to reliably identify the beginning and the end of each I Frame in order to provide accurate decoding of a video stream. The BTP I frame identification was originally designed for MPEG2, so the change to MPEG4 introduced problems.
A problem exists because, unlike with MPEG2, MPEG4 I frame data is interspersed between BTP packets. This change introduced a challenge to adapt the firmware design and algorithm to handle MPEG4 BTP video streams successfully with existing formats.
The adaptation for MPEG4 interspersing of I frame data between BTP packets resulted in problems, including: (1) a need for additional disk read operations. (2) More processing required to format the frame data to include the BTPs at appropriate offsets. (3) Introduction of overhead in data size to accommodate the BTP per frame. The overhead data had a direct impact on media clients, as they source data from the DVR hub/gateway device and handle the additional data sent across the network. The added overhead data resulted in significant added latency to the I frame processing and delivery to the decoder.
The result of the overall added latency is that DVR trickplay operations can be slow and choppy with MPEG4 relative to MPEG2. Fastforward speeds are not likely within acceptable thresholds. In some cases the 2× fastforward could take as long as the normal play speed of 1×. Accordingly, it is desirable to provide other methods to handle dispersement of BTP packets that are encoded in formats more recent than MPEG2 to avoid the problems discussed above.